Remarks 

This paper responds to the office action dated July 26, 2007. The rejections and 
objections set forth in the office action are specifically traversed. Reconsideration is 
respectfully requested in view of the above claim amendments and these remarks. 

Claims 22, 25, 27, and 35 are amended herewith. Claims 1-21, 23-24, 28-34, 36, 44- 
45, 49, and 52 have been cancelled, without prejudice. 

The "new matter" rejection of claims 22 and 27 has now been overcome by this 
amendment. Specifically, claim 22 has been amended to replace the phrase "consisting of 
with "including." Regarding the new matter rejection of claim 27, this claim has now been 
amended to be consistent with the description of the invention set forth in the patent 
application at page 18, line 29 through page 19, line 1. 

The 35 U.S.C. § 1 12 rejection of claims 22, 25 and 28 has also been overcome by this 
amendment. Specifically, claim 22 has been amended to include the parts of a computer 
based system, including a processor, a memory and a display for presenting the recited 
graphical user interface. 

The 35 U.S.C. § 101 rejection of claim 22 has also been overcome by this amendment. 
Specifically, the claim now clearly recites a statutory machine, i.e., a computer implemented 
medical record system comprising a display, a processor and a memory for storing computer 
readable instructions that cause the processor to render a graphical user interface on the 
display. 
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Finally, the 35 U.S.C. § 103 rejection over Lavin in view of Campbell is traversed 
because the combination of these two references fails to disclose or suggest: (1) automatically 
selecting a visit outline from a plurality of stored visit outlines in response to a selection of a 
patient's primary reason for visiting a medical service provider input to a reason for visit data 
entry field; (2) a visit outline which guides the examination by the medical service provider 
and listing the types of information that should be collected and recorded into the medical 
record system, the presented visit outUne including an item column listing information that 
should be collected by the medial service provider in relation to the selected primary reason 
for the patient's visit and a value column that lists the type or format of the collected 
information; and (3) dynamically modifying the presentation of the information set forth in 
the item column of the visit outline in response to a user making a selection from a pre- 
defined set of choices presented in the value column of the visit outline. 

1 . Lavin and Campbell Fail to Disclose or Suggest 
Automaticallv Selecting a Visit Outline 

Independent claim 22 recites the function of automatically selecting a visit outline 

from a plurality of visit outlines stored in the memory. This automatically-selected visit 

outline is related to the reason for the patient's visit that is input to the recited "reason for visit 

data entry field." An example of this "reason for visit" data entry field is shown below in 

Figure 7 as item 84. The "reasons for visit data entry field" (item 84) shown in Figure 7 is a 

drop down box that allows the medical service provider to select a primary reason for the 

patient's visit. In the example shown in Figure 7, "Chest Pain" is the primary reason selected. 
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The selections presented by this data entry field (item 84 in Figure 7) are linked, by the 
system, to one or more visit outlines that will assist the medical service provider by guiding 
the examination and by listing the types of information that should be collected and recorded 
into the medical record system. In the example of Figure 7, the selection "chest pain" is 
linked to a specific visit outline related to this problem and causes the system to automatically 
select and display the specific visit outline related to this problem. For example, as shown in 
Figure 8 of this application, set forth below, the selection of "chest pain" as the primary 
reason for the visit has triggered the "chest pain" visit outline in the patient history and 
physical examination screen. As shown in the left most column of the data entry screen, the 
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visit outline guides the examination by the medical service provider and lists the types of 
information that should be collected and recorded into the system. 




If the medical service provider had selected a different reason for the patient's visit in 
the reason for visit data entry field (84), then the system would have automatically selected a 
different visit outline to guide the examination. 

The office action admits that Lavin does not disclose the concept of a visit outline and 
thus it does not disclose the function of automatically selecting a visit outline from a plurality 
of stored visit outlines in response to the selection input to a reason for visit data entry field. 
(See, Office Action at page 6, "Lavin fails to expressly teach the selection received in the 
reason for visit data entry field automatically selects a visit outline. . .") 
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Campbell does not disclose this "automatic selection" function either. The office 
action refers to the following portions of Campbell in support of this teaching, but as clearly 
demonstrated below these portions of Campbell simply do not disclose the claimed 
functionality: (i) abstract of Campbell; (ii) col. 1, line 64 to col. 2, line 8; (iii) col. 2, lines 14- 
21; and (iv) col. 13, lines 10-18. 



|S7] ATTRACT 

A software ^mm fbr msaAgiiig a health ^are pratctkc 
includes inicradivc software tools fbr conducting a physical 
exam, suggcslSng tentative diagnosis, and managing aVrcat- 
mcnt profcieol. The physical exam soflware gwides the user 
Ihrough a physical exam, prompting the user for inpul ami 
dynamically generating CT)nlcx( sensitive qiicslions based on 
prior input. The tliagnoiis sofivvart sjcnoratcs a lisi of 
possible diagnoses based on the observaiions recordec! from 
the physical exam. Tlte user can interactively select » 
diagnoas by selecting a diagpasis from a rule out list and 
watching llie display as Ihe sy^ra dynamic updates the 
.status of «nre.solved symptoms, Itie u.ser can also select a 
treatment protocol, which is intt^raied with future piiysical 
vxmns. The ifcaimeotprolscoi: ttitcgratcd such th«( fiiture 
e xara sessions retkcl the status of the treatmen l protoco l a nd 
remind the u«er which services oced (o l» |)erfo»m«l mm! 
when they ^ould be perforroed. 



The Abstract of Campbell refers to "physical exam software," and a "list of possible 
diagnosis," and "selecting a treatment protocol," but it does not disclose or suggest a system 
having a plurality of visit outlines as recited in claim 22, the visit outlines being automatically 
selected based upon user input to a reason for visit data entry field. In fact, this portion of 
Campbell tends to indicate that there is only one programmed type of physical exam as 
distinguished from the "plurality of visit outlines that are programmed into the claimed 
system and which are automatically selected based upon the primary reason for the patient's 
visit. This is a very important advantage of the present invention because it enables the 
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medical service provider to more quickly gather the information necessary to make a 



diagnosis in response to the reason for the patient's visit, whereas in Campbell the user is 
likely required to enter data that is largely irrelevant to the patient's condition. Although 
Campbell's approach may be appropriate for a general physical examination in which there is 
no particular reason for the patient's visit, it is inefficient and time-consuming when the 
patient has come to the medical service provider with a specific problem, such as chest pain. 

The following additional portions of Campbell relied upon in the office action further 
demonstrate a lack of any teaching or suggestion of automatically selecting a visit outline 
from a plurality of visit outlines stored in the system in response to the specific problem 
identified by the user: 

When installed in a medical office or hcKspitai, the system 
software of the invention can be executed in a network 
contiguration or io a stand-alone computer. The syslem 
software displays interactive user interface screens for con- 65 
ducting an intcfactive medical exam, generating diagnoses 
of abnormal observations, and managing a treatment proto- 

2 

col The treatment protocol can be integrated with the 
ititeraciive tnedical exam component of the system. For 
example, the doctor can select a treatment protocol from a 
user interface displaying computer generated diagnoses. In 
5 response, the system schedules the treatment protocol such 
that future interactive exam sessions display reminders to 
perform services in the protocol, and prompt the user to 
make observations related to the selected diagnoses. Once 

(Campbell, col. 1, line 64 to col. 2, line 8) 
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The interactive mecHcal exam component of the system 
15 displays physical exam screens that guide the user through 
a complete medical exam. '^Tbe screens display precteter- 
mined observations atid enable the user to select among the 
observations to record abnormal findings. The system 
dynamically updates the patient'is record and evaluates the 
20 input to generate additional context sei^itive prompts to 
record additional observ^ations. 

(Campbell, col. 2, lines 14-21) 

When the user clicks on any of these buttons, the system IQ 
launches a new screen for the selected part of the physical 
exam. The interactive exam screens guide the user through 
the physical exam. As user enters information (by clicking 
on buttons or entering text), the server dynamically updates 
the database and evaluates the data to determine whether to IS 
prompt the user for additional information by displaying 
questions and supplemental screens that prompt the user to 
input medical observations. 

(Campbell, col. 13, lines 10-18) 

As clearly described in these portions of Campbell, his invention includes a single 

"physical exam" comprising a number of physical exam screens. These screens display 
predetermined observations and enable the user to select among the observations. Moreover, 
these "screens" are selected by the user of the system "when the user clicks on any of these 
buttons." Figure 4 of Campbell shows this manual or user selection of the various portions of 
the physical exam. When a user "selects" a button (420 in Figure 4), the system then brings 
up a predetermined physical exam screen (Figure 5) in response to the user selected portion of 
the physical exam. 
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Thus, Campbell teaches a single, predeteraiined physical examination which is broken 
down into a number of areas, such as "Overall Condition," "Coat and Skin," "Ocular," etc. 
The user of Campbell's system has to manually select one or more of these areas in order to 
be presented with a completely separate examination "screen" (Figure 5) that is used to 
collect information regarding the selected portion of the examination: ''The physical exam 
buttons represent the top level in a hierarchy of physical exam screens. The physical exam is 
broken into the following areas: 1) Overall Condition. . . 12) Behavioral. When the user 
clicks on any of these buttons, the system launches a new screen. . . " (Campbell at col. 12, 
line 59 to col. 13, line 11) 

Missing from Campbell is any disclosure or suggestion of linking the reason for the 
patient's visit, as input to the system in a reason for visit data entry field, with a specific visit 
outline that has been customized to guide the examination by the medical service provider in 
relation to the reason for visit. In Campbell, the examination screens are generic and 
unrelated to the reason for the patient's visit, whereas in the system disclosed and claimed in 
claim 22, the visit outlines are specific to the reason for the patient's visit and are designed to 
efficiently gather only the pertinent information relevant to that reason. 

In summary, Campbell does not disclose or suggest a plurality of visit outiines, but 
rather teaches a single physical examination broken down into a number of areas. Moreover, 
Campbell does not disclose or suggest automatically selecting one of the plurality of visit 
outlines in response to a selection of the primary reason for the patient's visit, but rather 
teaches that the user must manually select a sub-set of the single physical examination 
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process. Therefore, because this claimed subject matter is not disclosed or suggested in either 

of Campbell or Lavin, the obviousness rejection should be withdrawn. 

2. Lavin and Campbell Fail to Disclose or Suggest Visit Outlines 
Having an Item Column Listing and a Value Column Listing 

Claim 22 also requires that the visit outlines include "an item column listing 

information that should be collected by the medical service provider in relation to the selected 

primary reason for the patient's visit and a value column that lists the type or format of the 

collected information." An example of this claimed "visit outline" is shown in Figure 8 of the 

present application, set forth below. 
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As shown in this figure, the "visit outline" of the present invention includes a hierarchical 
item column listing (112) that is set forth in an "outline" form and which is configured to 
guide the examination by the medical service provider by listing, again in outline form, the 
types of information that should be collected. The claimed "visit outline" also includes a 
corresponding "value column" (114) which lists the type or format of the collected 
information. 

Neither Lavin or Campbell is configured to present the medical service provider with 
such a claimed "visit outline" having an item column listing and a value column listing to 
guide the collection of pertinent information by the medical service provider. First, as noted 
above, neither reference discloses the concept of a visit outline at all, but rather each reference 
teaches a generic user-selected examination process. Second, neither reference uses the dual- 
column outline structure shown in Figure 8, and recited in claim 22, to guide the examination. 
Instead, Campbell uses a distinct and separate examination screen for each portion of his 
single physical examination process. These separate examination screens in Campbell are not 
organized into an "outline" form either as shown in Figure 8 and recited in claim 22, but 
rather include a plurality of buttons, check-boxes, and other selector means (See Figure 5 of 
Campbell) that result in a very cluttered interface screen. There is simply no notion in 
Campbell of attempting to guide the medical examination through an outline form as recited 
in claim 22. 

Therefore, for this additional reason the 35 U.S.C. § 103 rejection over Lavin and 
Campbell should be withdrawn. 
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3 . Lavin and Campbell Fail to Disclose or Suggest 
Dynamically Modifying a Visit Outline 

Finally, claim 22 also recites the function of "dynamically modifying the presentation 
of the information set forth in the item column of the visit outline in response to a user 
making a selection from a pre-defined set of choices presented in the value column of the visit 
outline." In the present invention, as nov^ claimed, the visit outline itself is dynamic and the 
information to be gathered that is displayed in the item column (112 in Figure 8, above) 
changes depending upon user selections presented in the value column (114 in Figure 8, 
above). This functionality is completely missing from either Lavin or Campbell. 

As noted above, neither Lavin or Campbell disclose the concept of a visit outline as 
now recited in claim 22, and therefore neither reference can possibly disclose a dynamic visit 
outline in which the presentation of the information set forth in the item column of the visit 
outline changes in response to user selections in the value column. Although Campbell refers 
to a dynamic system, it does not disclose a visit outline, nor does it disclose modifying an 
item column portion of a visit outline in response to user selections. At best, Campbell 
discloses a process for collecting additional data, but this is in the context of additional data 
entry screens, not in the context of modifying an existing data entry mechanism such as a visit 
outline. 

Therefore, for this additional reason the 35 U.S.C. § 103 rejection over Lavin and 
Campbell should be withdrawn. 



CLl-1561773vI 



19 



For all of the reasons noted above, the obviousness rejection of claims 22 and 35 over 
Lavin in view of Campbell should be withdrawn. 

Although applicants maintain that the current amendment to the claims and the 
foregoing remarks put all of the claims in condition for allowance, applicants also specifically 
traverse the rejection of claims 25 for the reasons noted below. 

Claim 25 depends from claim 22 and adds the limitation of a carepath module that is 
Imked to the selected visit outline for suggesting a particular medical treatment in response to 
the data input in the first, second and third screens into the patient's chart, wherein the 
carepath module also automatically determines that additional data entry is required to 
evaluate the patient's condition in order to make a suggestion and prompts the user of the 
medical record system to input the additional data. 

The portions of Campbell relied upon in the office action as disclosing a carepath 
module refer to a "treatment protocol" which is displayed to the medical service provider. 
This appears to be a simple look up table type of implementation that does not provide any 
logic or intelligence built into the carepath. In the carepath module described in claim 25, for 
example, the suggestion of a particular medical treatment is made in response to the data input 
to the first second and third data entry screens, and, moreover, the carepath module is smart 
enough to determine that additional data is required in order to make a suggested treatment 
and thereafter automatically prompts the user to enter the needed data. In Campbell, by 
distinction, the "treatment protocol" must be manually selected by the medical service 
provider, it is not "linked to" a selected visit outline, nor does it make suggestions based upon 
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the data input to the system, nor does it automatically prompt the user to enter needed data 
suggest a treatment: "-The doctor can then launch a protocol by clicking on the protocol 
button. In response, the client sends a message to the server, which changes the status of the 
diagnosis to Undergoing therapy. . . To generate a protocol the server looks up the protocol 
in a protocol table using the selected diagnosis as a key.'' (Campbell, col. 17, lines 32-40) 
As demonstrated by this portion of Campbell, the "protocol" is manually selected by the 
doctor, and it is not linked to any visit outline but instead appears to be linked to a tentative 
diagnosis. Thus, Campbell does not disclose or suggest the functionality set forth in claim 25 
and therefore the obviousness rejection of this claim should be withdrawn. 
This application is now in condition for allowance. 



Respectfully submitted, 
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